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Preface 


! 


This  report  summarises  the  progress  made  towards 
developing  computer-based  system  to  perform  perception 
tests  using  light-emitting  diode  (LCD)  displays.  Since 
it  was  not  possible  to  test  the  design,  the  report  dis- 
cusses in  death  the  system  development  process.  The  re- 
quirements definition  and  initial  design  phase  which  are 
discussed  can  be  successfully  applied  to  any  software 
development  project.  This  report  is  written  for  a reader 
who  possesses  a basic  knowledge  of  software  development. 

I wish  to  thank  Captain  Larry  Goble  of  the  Air  Force 
Flight  Dynamic s Laboratory  for  his  support  throughout 
this  project.  A special  thanks  goes  to  my  thesis  advisor, 
Captain  J.  B.  Peterson,  for  his  encouragement,  assistance 
and  guidance  through  the  past  months. 

Robert  A.  Liebach 
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Abstract 


The  Multi-Mode  Matrix  Display  Program  is  attempting 
to  test  the  acceptability  of  using  light-emitting  diode 
displays  in  U5AF  aircraft.  The  informal  and  formal  func- 
tional specifications  for  the  software  necessary  to  per- 
form the  desired  tests  have  been  developed.  Formal  func- 
tional specifications  were  developed  using  a technique 
called  structured  analysis.  The  functional  specifications 
were  used  to  design  the  software  system.  This  design  was 
accomplished  using  structured  design  techniques.  The  soft- 
ware design  is  presented  using  structure  charts  together 
with  functional  descriptions  of  all  modules  and  definitions 
of  the  interfaces  between  modules. 


VII 


I.  INTRODUCTION 


Scope 

The  Multi-Mode  Matrix  Display  ( MUM ) project  office  is 
attempting  to  develop  light-emitting  diode  (LCD)  displays 
to  replace  CRT  displays  currently  being  used  in  U3AP  air- 
craft. Part  of  the  effort  being  conducted  by  the  M MM  of- 
fice is  to  perform  human  factors  research  on  dot  matrix 
symbology  to  determine  the  acceptability  of  using  1UD  dis- 
plays.  Specifically,  the  MMM  office  is  interested  in  tes- 
ting the  effects  on  human  perception  caused  by  the  rotation 
vibration  and  degradation  of  an  LSD  display  image. 

This  thesis  is  concerned  with  designing  the  software 
necessary  to  accomplish  the  MMM  project  test  objectives, 
without  making  any  assumptions  concerning  the  hardware  ar- 
chitecture which  will  be  used  to  implement  the  system. 

The  software  design  consists  of  designing  the  necessary 
subsystems,  programs  or  modules,  and  their  interconnections 
It  is  not  the  intent  of  this  thesis  to  devlop  design  spe- 
cifications or  to  produce  any  urogram  code. 

Objectives 

/hen  developing  computer  software  there  is  a great 
tendency  to  start  producing  code  at  the  very  beginning  of 
the  project.  This  has  proven  to  be  a very  ncor  approach 
to  software  development , since  these  projects  have  frequent 
ly  experienced  cost  overruns,  missed  schedules  and  disgrun- 
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tied  users.  Sven  in  projects  where  top-down  structured 
programming  techniques  were  used,  the  resulting  software 
has  frequently  been  plagued  with  problems.  A prime  exam- 
ple of  this  latter  case  is  IBM’s  New  York  Times  system 
which  has  many  maintenance  problems. 

In  virtually  all  of  the  above  cases,  the  problems  were 
the  result  of  poor  software  design  (or  the  lack  of  any 
software  design).  The  primary  objective  of  this  thesis  is 
to  avoid  the  problems  mentioned  above  by  designing  the 
system  software  architecture. 

To  meet  the  primary  objective,  it  is  first  necessary 
to  develop  the  ton-level  system  performance  specifications 
on  a functional  basis.  This  consists  of  precisely  des- 
cribing the  user  inputs  to  the  system  and  the  outputs  de- 
sired by  the  user.  The  algorithms  for  information  storage, 
transfer  and  manipulation  are  also  described. 

After  the  functional  specifications  have  been  defined, 
the  structure  of  the  software  can  be  designed.  The  design 
is  accomplished  through  the  application  of  structured  de- 
sign techniques,  which  reduce  the  complexity  of  programs 
by  dividing  them  into  functional  modules.  This  makes  it 
possible  to  create  complex  systems  from  simple,  relatively 
independent  modules.  The  resulting  design  facilitates  the 
debugging,  modification  and  maintenance  of  the  software 
system. 
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Design  Constraints 


Design  constraints  are  the  conditions  >.  hich  specify 
how  the  system  is  to  be  inclement cd . The  design  con- 
straints do  not  necessarily  define  the  particular  items 
which  will  be  used  to  realize  the  system.  Rather,  they 
identify  limits  ••hich  may  later  be  used  in  the  selection  or 
creation  of  the  hardware  or  soft'. 'are  which  is  used  to  im- 
plement the  system. 

Good  design  practices  advise  that  details  of  the  de- 
sign, and  binding  implementation  decisions,  be  postponed 
to  later  phases  of  the  system  lif e-cjrcle . Typically  this 
is  not  the  case  however,  since  a designer  may  be  given  pre- 
mature budget  or  hardware  constraints.  Frequently  the  de- 
signer is  constrained  to  use  a particular  piece  of  hardware 
hich  has  already  been  purchased,  even  though  that  hardware 
may  not  result  in  the  best  implementation  of  the  system. 

Then  this  investigation  was  started,  no  firm  decisions 
had  been  made  concerning  the  hardware  which  would  be  used 
to  implement  the  system.  It  -was  assumed  that  a minicompu- 
ter in  the  PDP-11  class  would  be  used,  but  this  assumption 
had  no  impact  on  the  design  which  was  developed.  In  addi- 
tion, no  assumptions  were  made  concerning  the  operating 
system  which  would  be  purchased  with  the  system  hardware, 
nor  were  any  cost  constraints  imposed  on  the  design.  As  a 
result,  the  design  developed  in  this  thesis  made  no  assump- 
tions concerning  the  computer  or  peripheral  devices  (I/O 
and  storage)  which  would  be  used.  Therefore,  the  design 


3 


which  is  presented  makes  reference  to  "input  from  a console" 


or  "output  to  mass  storage"  without  giving  any  description 
of  the  particular  device  (or  possible  operating  system  rou- 
tines) which  will  be  used. 

Outline 

The  informal  functional  specifications  for  the  system 
are  discussed  in  Chapter  II.  Chapter  III  presents  the  for- 
mal functional  specifications  for  the  system  using  activity 
and  data  models  which  result  from  the  application  of  struc- 
tured analysis.  Chapter  IV  presents  the  software  design 
using  structure  charts  together  with  functional  descriptions 
of  the  modules  in  the  design.  Conclusions  are  presented  in 
Chapter  V along  with  recommendations  for  the  effort  neces- 
sary to  complete  the  software  development. 


II.  REQUIREMENTS  DEFINITION 


Introduction 

The  normal  system  life-cycle  for  a computer  software 
(or  hardware)  development  project  consists  of  the  following 
seven  phases  (Ref  1:5-8):  conceptual,  requirements  defi- 

nition, design,  coding  and  checkout,  testing  and  operation- 
al. Requirements  definition  is  the  second  phase  in  the 
system  life-cycle,  and  it  is  recognized  as  one  of  the  most 
critical  of  all  the  phases.  It  is  during  this  phase  that 
a complete  and  consistent  set  of  requirements  is  developed 
for  the  system. 

Numerous  problems  typically  occur  in  projects  where  a 
good  set  of  requirements  is  not  developed  early  in  the  pro- 
ject. Some  of  the  problems  which  have  resulted  are  missed 
schedules,  cost  overruns  and  dissatisfied  users,  since  the 
system  does  not  perform  the  way  the  viser  wants  (Ref  3s2). 

During  the  last  several  years,  the  computer  industry 
has  become  increasingly  aware  of  the  importance  of  require- 
ments definition.  Several  different  methods  or  aids  have 
been  developed  to  assist  in  developing  good  system  require- 
ments. One  of  these  methods  is  structured  analysis  (Ref  3), 
which  provides  a graphic  language  which  can  be  used  to  spe- 
cify the  requirements  of  a system  (see  Chapter  III). 

A computerized  aid  which  has  been  developed  is  the 
Problem  Statement  Language/Problem  Statement  Analyzer 
(Ref  6).  P3L/P3A  is  a tool  for  describing  both  the  hard- 
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ware  and  software  of  information  processing  systems  and  re- 
cording the  descrintions  in  machine-processable  form.  The 
data  base  which  is  created  is  analyzed  for  logical  correct- 
ness and  consistency  by  the  computer.  The  computer  system 
can  also  be  used  to  produce  various  reports  on  all  or  any 
selected  part  of  the  data  in  the  data  base. 

Requirements  definition  typically  deals  with  three 
different  subjects  (Ref  3:4):  context  analysis,  functional 

specification  and  design  constraints.  Context  analysis 
deals  primarily  with  the  reasons  why  the  system  is  to  be 
created.  As  discussed  in  Chapter  1,  context  analysis  is 
considered  beyond  the  scone  of  this  thesis.  Functional 
specification  is  a description  of  what  the  system  is  to  ac- 
complish in  terms  of  the  functions  it  is  to  perform,  and 
is  discussed  in  the  following  section  and  in  Chapter  III. 

The  conditions  specifying  how  the  system  is  to  be  implemen- 
ted is  the  subject  of  the  design  constraints,  which  were 
discussed  briefly  at  the  end  of  Chapter  I. 

Functional  Specifications 

General  Specif ications . The  system  to  be  designed 
will  be  used  to  perform  perception  experiments.  A tynical 
perception  test  consists  of  displaying  a sequence  of  symbols 
end  recordin'*  a subject’s  responses.  The  software  system 
will  hove  three  basic  modes  of  operation:  3et-Uo,  Experi- 

ment ixecution  and  Data  Analysis. 

Tlie  Set-Up  mode  of  operation  allows  the  user  to  enter 
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test  parameters  to  perform  a particular  experiment.  During 
this  mode  of  operation,  the  system  .'ill  output  a series  of 
messages  to  the  user  to  choose  the  options  and  enter  the 
parameters  to  be  used  during  execution  of  the  experiment . 

/hen  the  system  is  put  into  the  Experiment  Execution 
mode,  a message  will  be  output  to  the  experiment  subject, 
requesting  the  subject  to  enter  identification  information 
(name,  date,  etc.).  The  system  will  then  begin  displaying 
a series  of  symbols  (according  to  the  parameters  and  options 
entered  during  the  Set-Uo  mode)  and  recording  the  symbols 
and  subject  responses  for  later  analysis. 

The  Data  Analysis  mode  of  operation  is  used  to  reduce 
the  data  gathered  during  an  experiment  into  a more  useful 
form.  For  example,  commands  can  be  given  to  generate  con- 
fusion matrices  or  to  execute  collapsing  routines,  as  dis- 
cussed at  the  end  of  this  chapter. 

'hen  the  system  is  initialized  (turned  on),  it  will 
operate  in  an  executive  mode  which  ".'ill  request  the  user  to 

choose  one  of  the  three  basic  modes  of  operation.  ./hen  the 

f 

user  wishes  to  change  from  one  mode  to  another,  he  will 
first  enter  a command  to  terminate  the  current  mode  of 
operation.  The  termination  command  causes  the  system  to 
return  to  the  executive  mode,  from  which  the  user  can  a- 
gain  choose  any  of  the  basic  modes  of  operation. 

The  system  must  be  designed  so  that  it  is  easy  to  use. 
Thus,  the  system  will  output  requests  to  the  user  to  in- 
put commands,  and  the  parameters  associated  with  the  com- 
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mand.  However,  since  a frequent  user  of  the  system  will 
probably  not  require  the  system  to  request  the  parameters 
associated  with  a command,  the  system  will  allow  the  user 
to  input  a command  .and  its  parameters  at  the  same  time. 

Set-Up  Mode  of  Operation.  This  mode  of  operation  al- 
lows the  user  to  choose  the  options  and  to  input  the  para- 
meters to  be  used  for  a particular  experiment.  /hen  put  in 
the  Set-Up  mode,  the  system  will  outpxrfc  a message  telling 
the  user  that  it  is  in  the  Set-Up  mode.  The  user  may  then 
enter  any  of  the  commands  from  Table  I.  If  any  other  com- 
mand is  entered,  the  system  will  respond  with  an  error  mes- 
sage and  request  that  the  command  be  reentered.  A descrip- 
tion of  each  of  the  commands  of  Table  I follows. 

Table  I 

Set-Up  Commands 

LIBRARY 

MASKS 

SYMBOL  DISPLAY  DYNAMICS 
TIME  PARAMETERS 
STIMULUS  LIST 
DISPLAY  SEQUENCE 
PRINT 

SET-UP  PARAMETERS 
END  SET-UP 

1.  LIBRARY.  The  system  must  provide  the  capability 
to  input,  store  and  recall  a set  of  symbols.  ./hen  the  user 
enters  the  L IBR ARY  command,  the  system  will  respond  by  re- 
questing the  user  to  choose  one  of  the  following  functions: 
CREATE,  STORE,  DISPLAY,  PURGE,  ALTER,  LIST,  or  END.  If  any 
other  command  is  entered,  the  system  will  respond  with  an 
error  message  and  request  that  the  command  be  reentered. 
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The  CREATE  command  causes  the  system  to  respond  with 
a request  for  the  symbol  characteristics.  The  system  must 
provide  the  curability  to  enter  the  characteristics  of  any 
symbol,  by  defining  the  individual  elements  of  the  display 
which  are  to  be  lit  or  extinguished.  The  parameters  can  be 
entered  one  at  a time,  or  a series  of  parameters  can  be 
entered  (e.g.,  parameters^,  parameter^,  ...).  The  user  can 
also  specify  that  the  display  be  cleared,  in  preparation 
for  defining  a new  symbol. 

The  IT ORE  command  causes  the  characteristics  of  the 
symbol  which  is  currently  displayed  to  be  entered  into  the 
library.  The  system  responds  to  the  5T0RE  command  by  re- 
questing that  an  index  for  the  symbol  be  entered.  Vhen  the 
index  is  entered,  the  system  will  check  that  the  index  is 
not  identical  to  an  index  already  in  use.  If  the  index  is 
invalid,  the  system  will  request  that  the  xiser  enter  a dif- 
ferent index. 

To  delete  a symbol  from  the  library,  the  user  v'ould 
enter  the  PURGE  command.  The  system  would  respond  by  re- 
questing an  index  number.  If  a valid  index  number  is  en- 
tered, the  system  would  delete  the  corresponding  symbol:  if 
an  invalid  index  were  inputted,  the  system  would  respond 
with  an  error  message. 

The  DISPLAY  command  allows  the  user  to  display  any 
symbol  in  the  library.  The  system  responds  to  the  DISPLAY 
command  by  requesting  the  user  to  enter  an  index.  If  a 
valid  index  is  inputted,  the  system  'will  display  the  cor- 
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responding  symbol.  The  system  will  respond  with  an  error 
message  if  an  index  is  entered  which  is  not  in  the  library. 

The  ALTER  command  allows  the  user  to  test  the  symbol 
display  dynamics.  After  this  command  is  entered,  the  sys- 
tem will  request  the  user  to  incut  a ROTATE,  ADD /DELETE, 
JITTER  or  VIBRATE  function,  and  the  associated  command  na- 
rameters  (see  3 below).  The  user  may  specify  that  only 
one,  or  a combination  (e.g.,  rotate  and  vibrate)  of  the 
functions  be  used.  The  system  will  respond  by  performing 
the  selected  functions  on  the  symbol  which  is  currently  be- 
ing displayed.  Thus,  the  ALT BR  command  allows  the  user  to 
preview  the  effects  of  the  symbol  modifications  prior  to 
performing  the  experiment.  The  ALTER  functions  will  re- 
main in  effect  until  the  END  ALTER  command  is  inputted,  af- 
ter which  the  user  can  again  enter  any  of  the  commands  in 
Table  I. 

The  LIST  command  allows  the  user  to  request  the  sys- 
tem to  output  the  indexes  of  all  the  symbols  currently  in 
the  symbol  library  or  to  output  the  number  of  symbols  in 
the  library  (by  using  the  .ALL  or  NUMBER  options).  ./hen 
the  user  enters  the  END  command,  the  system  will  return  to 
the  Set-Up  mode  of  operation,  where  it  will  again  accent 
any  of  the  commands  shown  in  Table  I. 

P.  MASKS . During  performance  of  the  experiment,  the 
system  may  be  required  to  display  a random  symbol  (called 
a mask)  before  and/or  after  the  stimulus  symbol  is  dis- 
played. The  system  must  be  capable  of  producing  two  kinds 


of  masks:  static  and  dynamic. 

A static  mask  is  a symbol  which  has  random  characteris- 
tics which  do  not  change  during  the  display  time.  The  sys- 
tem must  be  able  to  nrortuce  and  store  these  masks  prior  to 
performance  of  the  experiment . Dynamic  masks  are  random 
symbols  which  are  created  during  performance  of  the  experi- 
ment. Unlike  static  masks,  dynamic  masks  change  appearance 
during  the  display  time. 

./hen  the  HACK!  command  is  entered,  the  system  will  re- 
quest the  user  to  choose  whether  static  or  dynamic  masks 
are  to  be  used.  If  the  user  enters  3TATIC , the  system  will 
respond  by  asking  the  user  to  input  the  total  number  of 
masks  to  be  generated  and  stored,  the  maximum  number  of 
elements  to  be  lit  for  a mask  and  any  constraints  on  the 
randomness  of  the  mask.  The  randomness  constraints  will 
consist  of  requiring  that  the  mask  consist  of  line  segments, 
or  a constraint  on  which  adjacent  elements  of  a lit  ele- 
ment may  also  be  lit. 

For  dynamic  masks,  the  system  will  request  the  user 
to  input  the  time  interval  between  lighting  elements.  The 
system  will  also  request  the  user  to  input  the  persistence 
time  for  an  element  (the  length  of  time  an  element  is  to 
be  lit)  if  an  LED  display  is  being  used. 

If  the  user  does  not  respond  with  either  STATIC  or 
DYNAMIC , the  system  will  output  an  error  message  and  re- 
quest that  the  command  be  repeated.  After  the  mask  charac- 
teristics or  END  option  is  inputted,  the  system  will  return 
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to  the  3et-Ut)  mode  of  operation. 


I* 


A.  lYI/iBOL  DISPLAY  DYNAMIC 3 . The  system  must  pro- 
vide the  capability  to  perform  certain  modifications  (such 
as  rotation  or  vibration)  to  the  symbol  displayed  during 
the  performance  of  the  experiment.  After  the  SYI.IBOL  DI3- 
PL AY  DYN AMIC 3 command  is  entered,  the  system  will  respond 
by  asking  the  user  to  enter  one  of  the  following  options: 
ROT AT 3 , ADD/ DELETE,  JITTER,  VIBRATE,  or  END. 

'..'hen  the  user  enters  the  ROTATE  option,  the  system 
will  respond  by  requesting  the  usex-  to  choose  between  a 
constant  or  random  rotation.  If  the  user  chooses  a con- 
stant rotation,  the  system  will  request  that  the  rotation 
angle  be  inputted.  For  a random  rotation,  the  system  will 
request  the  maximum  allowable  angle  of  rotation. 

The  ADD/DELETE  ootion  allows  the  user  to  modify  a sym- 
bol by  having  the  system  randomly  remove  or  add  portions 
of  a symbol.  vhen  this  option  is  chosen,  the  system  re- 
quests the  user  to  input  the  number  of  elements  which  are 
to  be  randomly  added  and  the  number  of  elements  which  are 
to  be  randomly  removed.  The  user  will  have  the  option  of 
entering  one  add/delete  parameter  which  will  be  used  for 
all  the  symbols  in  the  stimulus  list,  or  he  can  enter  a 
different  add/delete  parameter  for  each  symbol  in  the  sti- 
mulus list. 

Jitter  causes  the  symbol  to  be  randomly  located  within 
a specified  region  of  the  display.  After  entering  the 
JITTER  option,  the  user  will  be  asked  to  input  the  allow- 
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able  range  of  movement.  The  VI BRAT I OH  option  allows  the 


user  to  specify  the  range  of  movement  and  the  frequency 
that  the  displayed  symbol  should  be  vibrated.  The  JITTER 
and  VIBRATION  options  are  mutually  exclusive.  If  neither 
of  these  options  is  chosen  during  the  3et-Up  mode,  then 
the  symbols  displayed  during  performance  of  the  experiment 
will  not  be  jittered  or  vibrated. 

After  any  of  the  above  commands  are  entered,  the  sys- 
tem will  respond  with  a request  to  choose  another  symbol 
modification  option.  Thus,  the  user  can  specify  that  sym- 
bols displayed  during  the  experiment  are  to  have  multiple 
modifications  (i.e.,  symbols  are  to  be  rotated  and  vibrat- 
ed simultaneously) . To  return  to  the  3et-Uo  mode  of  opera- 
tion, the  user  would  enter  the  END  option. 

4.  TINE  P AR ilMET ED 3 . During  performance  of  the  experi- 
ment, the  system  will  be  required  to  display  a sequence  of 
symbols  consisting  of  an  acknowledgement  symbol,  a mask, 
the  stimulus  symbol  followed  by  a second  mask,  and  a re- 
displaying of  the  acknowledgement  symbol.  There  are  seve- 
ral time  intervals  associated  with  this  display  sequence: 

’Task  Time^  - length  of  time  to  display  the  first  mask 

Mask  Delay-,  - time  interval  between  the  end  of  display- 
ing the  first  mask  until  the  beginning  of 
displaying  the  stimulus 

Itimulus  Time  - length  of  time  the  stimulus  is  to  be 
displayed 

Mask  Delay,-,  - the  delay  between  the  end  of  displaying 
the  stimulus  until  the  beginning  of  the 
second  mask 


Mask  Time,,  - the  length  of  time  the  second  mask  is  to 
be  displayed 

Prompting  Delay  - maximum  time  the  system  should  wait 

for  a response  before  displaying  a 
prompting  message 

5.  STILILUl  Lid?.  The  stimulus  list  is  a set  of  sym- 
bols which  are  taken  from  the  library  to  be  used  during  a 
particular  experiment.  After  entering  STiriTJLUS  LIdT,  the 
system  will  request  the  user  to  enter  the  indexes  for  the 
symbols  to  be  used  as  the  stimulus  list.  The  user  also 
will  be  requested  to  specify  whether  the  symbols  should  be 
displayed  in  order  from  the  stimulus  list,  or  if  the  sys- 
tem should  take  them  in  a random  order. 

6.  DISPLAY  5BQtreNC3.  This  command  allows  the  user 
to  enter  parameters  to  control  the  sequence  in  which  sym- 
bols are  displayed  during  the  experiment.  One  option 
which  can  be  specified  is  the  acknowledgement  symbol  to  be 
used.  The  user  may  also  choose  a reinforcement  option 
which  causes  the  system  to  display  a correct/incorrec  o ack- 
nowledgement after  each  subject  response. 

Another  option  the  user  can  specify  concerns  the  re- 
moval of  a symbol  from  the  stimulus  list  based  upon  the 
subjects  responses.  /hen  this  option  is  chosen,  the  user- 
will  be  requested  to  input  the  number  of  consecutive  times 
the  subject  must  correctly  respond  to  a symbol  for  the  sym- 
bol to  be  removed  from  the  list. 

In  addition,  the  user  can  also  choose  an  option  .hich 
causes  the  system  to  redisplay  the  same  symbol  if  the  sub- 
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ject  responds  incorrectly. 

7.  PRINT.  The  system  must  be  capable  of  producing  a 
print-out  of  the  symbols  and  subject  responses  during  the 
execution  of  the  experiment.  The  PRINT  command  allows  the 
user  to  specify  that  the  system  is  to  print  the  index  of 
the  displayed  symbol , the  symbol  display  dynamics,  the  sub- 
ject's response  and  response  time. 

8.  SET-UP  PARAMETERS.  The  system  must  allow  the 
user  to  store  all  of  the  set-up  parameters  used  for  a par- 
ticular experiment.  The  SET-UP  PARAMETERS  command  allows 
the  user  to  enter  the  STORE,  RELOAD,  PRINT  and  ERASE  op- 
tions. .Vith  the  STORE  option,  the  user  can  soecify  that 
the  current  set-up  parameters  are  to  be  retained  in  oerma- 
nent  storage  for  later  use.  The  HELP  ID  option  allows  the 
user  to  recall  a previous  set  of  parameters  and  the  PR INT 
option  causes  the  current  set-up  parameters  to  be  nrinted 
out.  The  ERASE  option  is  used  to  delete  a set  of  oarameters 
from  permanent  storage. 

9.  END  SET-UP . This  command  causes  the  system  to 
exit  the  Set-Up  mode  and  to  return  to  the  executive  mode. 

Experiment  Execution  Node.  After  the  set-up  parameters 
and  options  have  been  specified,  the  user  can  command  the 
system  to  begin  executing  the  experiment,  when  the  system 
enters  this  mode,  it  will  ouvput  a message  to  the  experi- 
ment subject,  requesting  that  identification  information 
(name,  date,  etc.)  be  inputted.  The  system  .ill  continue 
to  display  this  request  until  a response  is  received  from 
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the  subject  or  the  user  enters  the  iJND  3RIF  'NT  HODZ  in- 


struction. 

If  the  subject  responds  with  an  ID,  the  system  \ ill 
then  display  the  acknowledgement  symbol  indicating  that 
the  test  is  about  to  begin.  The  system  will  then  begin  dis- 
playing the  mask,  stimulus  symbol,  mask  and  acknowledgement 
symbol  sequence  according  to  the  set-up  parameters.  For 
each  response  from  the  subject,  the  system  will  record  the 
displayed  symbol,  the  symbol  display  dynamics,  the  subject's 
response  and  response  time.  The  experiment  will  continue 
to  run  until  the  subject  enters  the  3 TOP  command,  which  will 
cause  the  system  to  output  an  "end  of  experiment"  message. 
The  system  will  then  redisplay  the  request  for  ID  informa- 
tion in  preparation  to  test  another  subject. 

The  system  will  allow  the  siibject  to  input  two  special 
responses.  The  first  is  an  indicator  that  the  subject  has 
hit  the  wrong  key  when  making  a response.  This  indicator 
can  be  given  between  the  time  the  subject  has  responded  to 
a symbol  and  before  he  responds  to  the  next  symbol.  If 
the  subject  indicates  that  he  has  hit  the  wrong  key,  the 
system  will  flag  the  stored  data  for  his  resnonse  and  the 
experiment  will  continue.  The  second  special  response  is 
an  "I  don't  know"  indicator,  which  the  subject  can  use  if 
he  is  not  sure  what  the  displayed  symbol  was. 

Data  Analysis  J.'ole . The  system  must  be  capable  of 
performing  analysis  on  the  results  of  one  or  more  experi- 
ments. To  accomplish  the  analysis,  the  system  is  required 
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to  generate  confusion  matrices  and  also  to  perform  a col- 
lapsing routine. 

There  are  three  different  confusion  matrices  which  are 
to  he  generated.  As  an  example,  assume  the  following  for 
the  results  of  an  experiment: 

Symbol  Presented  Subject  Response  Reaction  Tim 
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Figure  1.  Sample  Confusion  Matrices 

Figure  1(a)  shows  the  first  type  of  confusion  matrix, 
■which  gives  the  number  of  times  a given  symbol-presented/ 
subject-response  occurred.  In  Figure  1(b),  the  subject’s 
response  time  is  clotted.  Figure  1(c)  shows  the  percentage 
of  times  a given  symbol -ere sent ed/sub j ect-response  occurred. 

A collapsing  routine  uses  a predictor  matrix  to  reduce 
the  data  contained  in  a confusion  matrix  into  a more  use- 
ful form.  The  collapsing  routine  consists  of  performing  a 
comparison  of  a confusion  matrix  -with  a given  eredictor  ma- 


trix  (see  Figure  2).  The  comparison  is  accomplished  by 
first  finding  the  cells  in  a confusion  matrix  which  cor- 
respond to  a given  rank  (order  number)  of  the  predictor 
matrix,  or  which  correspond  to  a given  range  of  absolute 
distance  taken  from  the  nredictor  matrix.  The  value  con- 
tained in  the  corresponding  cells  of  the  confusion  matrix 
■are  then  summed  to  oroduce  the  desired  result. 
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Figure  2.  Sample  Predictor  Matrix 

For  example,  the  confusion  matrix  in  Figure  1(b)  could 
be  collapsed  using  the  oredictor  matrix  of  Figure  2 to  give 
the  Rank  1 reaction  time.  First,  the  rank  1 cells  from  Fi- 
gure 2 are  found  (cells  AC,  BE,  CD,  DE,  EF,  and  ?E) . Then 
the  entries  in  the  corresponding  cells  of  the  confusion  ma- 
trix are  found  (the  entries  are  0.6,  0.4,  and  0.5).  The 
values  of  the  entries  are  then  summed  to  give  a resu.lt  of 
1.5. 
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The  following  is  a summary  of  the  commands  used  during 
the  analysis  mode: 

LOAD  PIT A - this  command  allows  the  user  to  enter  the 

ID  for  each  of  the  experiment  restilts  which 
are  to  be  analyzed 

CONFUSION  (ootion)  - after  this  oction  is  entered,  the 

user  can  specify  which  confusion 
matrices  are  to  be  generated 

IS3P0N3N  - generates  response  confusion  matrix 

REACTION  TITJN  - generates  reaction  time  confusion 
matrix 

P jlC CNIAGB  - generates  percentage  confusion  matrix 

PUNT  - outputs  the  generated  confusion  matrix 

PREDICTOR  (option)  - this  option  allows  the  user  to  en- 
ter a predictor  matrix  and  perform 
a collapsing  routine 

CUT  NR  - after  this  command  is  entered,  the  system 
will  request  the  user  to  incut  a nredictor 
matrix 

RANK , number  - this  command  causes  the  system  to  col- 
lac  se  the  confusion  matrix  based  on 
the  given  rank  number 

ABSOLUT  3 PICT  INC  T , range  - this  command  causes  the 

system  to  collapse  the  con- 
fusion matrix  based  on  the 
given  absolute  distance 
range 
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III.  PORT’.TAL  FUNCTIONAL  SPECIFICATIONS 


Introduction 

The  formal  functional  specifications  of  the  system 
were  developed  using  structured  analysis,  as  mentioned  in 
Chapter  II.  Structured  analysis  consists  of  creating  mo- 
dule diagrams  using  a blueprint  like  language.  These  dia- 
grams show  a "ton-down"  decomposition  of  the  system  being 
analyzed,  from  both  an  activity  and  a data-oriented  ner- 
spcctive  as  defined  below . 

Structured  analysis  uses  the  concept  of  modularity  to 
analyze  complex  system  structures  by  successively  breaking 
down  the  subject  matter  into  smaller,  well  defined  modules. 
The  goal  of  structured  analysis  is  to  break  the  system  down 
into  modules  which  are  small  enough  to  be  easily  understood 
and  whose  interfaces  with  other  modules  can  be  clearly  seen. 

To  describe  a complex  system  completely,  there  are  to 
basic  aspects  which  must  be  covered:  the  functions  tier- 

formed  by  the  system  and  the  things  upon  which  the  functions 
act.  In  structured  analysis,  the  functions  are  called 
"activities"  and  the  things  are  called  "data".  Structured 
analysis  decomposes  the  system  twice:  once  based  on  its 

activities  (called  the  activity  model)  and  again  in  a sepa- 
rate model  based  on  its  data  (called  the  data  model).  Thus, 
the  system  is  examined  twice,  resulting  in  a thorough  func- 
tional specification  of  the  system. 

The  next  section  of  this  chapter  presents  the  activity 
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model  for  the  system.  The  lust  section  of  the  chunter 
presents  the  data  model.  The  reader  is  referred  to  Anoen- 
dix  A for  a presentation  of  ho/  to  read  structured  analy- 
sis di  agr  rams . 
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Figure  3.  Perform  Perception  Experiment  (Context) 
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Figure  4,  Perform  Perception  Experiment 
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Text . The  set-ut>  parameters  (101)  are  obtained 
from  bulk  input  (111)  or  from  the  user  set-up  commands 
(101).  Once  the  set-uo  parameters  have  been  generated, 
they  can  be  outputted  (101)  to  be  stored  or  they  can  be 
used  to  control  the  execution  of  an  experiment  (201).  Exe- 
cute Experiment  (2)  nroduces  the  experiment  results  (201), 

t 

.vhich  can  be  outputted  or  they  can  be  inputted  (311)  to 
Perforin  Analysis  (3).  Perform  Analysis  (3)  uses  the  experi- 
ment results  and  the  bulk  innut  (312)  to  analyze  the  re- 
sults of  experiments,  subject  to  the  user  commands  (301). 

The  bulk  input  (Alp)  can  consist  of  the  results  of  other 
experiments  and  other  data  necessary  to  accomplish  the  an- 
alysis (e.". , a oredictor  matrix). 


Figure  5.  Process  User  Commands 


-11  Text.  User  set-up  commands  (1G1)  are  checked  to 


determine  if  they  are  valid  by  (l).  If  the  command  is  in- 
valid, an  error  message  is  generated  (102).  For  valid  com- 
mands, (l)  determines  if  the  command  parameters  have  been 
inputted,  and  requests  the  user  to  input  these  narameters 
(101)  if  they  have  not  been  entered.  Get  V lid  Command  (1) 
also  determines  if  the  command  is  a library  command  (102) 
or  any  of  the  other  set-up  commands  (104). 

The  other  set-up  commands  (?C1)  are  used  by  Handle 
Set-Up  Parameters  (2)  to  generate  the  set-un  parameters 
( 701)  or  to  control  the  generation  of  the  set-up  parameters 
(201)  from  bulk  inputs  (:'Il).  If  (2)  receives  a valid  coal- 
man! which  has  invalid  command  parameters,  on  error  mes- 
sage (202)  is  outputted. 

Valid  library  commands  (2C1)  are  used  to  control  the 
performance  of  library  functions  (3).  For  a library  LI >T 
command,  the  requested  output  (30?)  is  sent  to  (5).  Li- 
brary A.LTHR  commands  are  performed  by  (4).  which  rets  the 
parameters  (411)  from  (?)•  If  (3)  receives  invalid  para- 
meters for  a command  (e.g.,  an  invalid  symbol  index)  it 
outputs  an  error  message  (301). 
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Node-.  All 


Figure  6.  Get  Valid  Command 


ill  Ter t . Check  Command  (l)  inputs  user  commands 


(ill)  and  checks  if  the  command  is  valid  and  if  the  neces- 
sary command  parameters  have  been  inputted.  If  the  command 
is  invalid,  an  error  message  (101)  is  outputted.  For  a va- 
lid command  which  does  not  have  the  necessary  command  para- 
meters ( ::C1),  Get  Parameters  (?)  outputs  a request  ( 101) 
for  the  parameters.  The  parameters  are  inputted  ( '"'ll ) which 
results  in  a valid  command  with  parameters  to  be  outputted 
("Of)  to  Determine  Type  Command  (3). 
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Figure  7,  Handle  Set-Up  Parameters 


A.1  Text . Check  Parameters  (1)  receives  set-up  com- 
mands (101)  or  bulk  set-up  parameters  (111)  and  checks 
their  validity.  It  an  error  is  found,  an  error  mess'-me 
(101)  is  generated.  Valid  parameters  (112)  are  passed  to 
(2)  no  (3).  Temporary  Parameter  Store  (')  stores  the  pa- 
rameters for  use  by  A. 2 : Permanent  Parameter  Store  stores 
the  symbols  also,  and  ..-hen  directed  by  user  commands  ( 3G  2 ) 
generates  a permanent  copy  of  the  parameters  ( 01)  which 
can  later  be  loaded  as  bulk  set-up  parameters. 
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Node : A13 


Figure  6.  Perform  Library  Function 


A13  Text . Determine  Command  Type  (l)  determines  '.vhich 


library  command,  has  been  inputted  (111)  and  outputs  the 
command  to  the  appropriate  module.  Symbol  parameters 
I?01,  302)  are  generated  by  the  create  function  (2)  or  by 
recalling  the  oarameters  ( 3 )~~  froa--' the _ symbol  library.  For 
the  STORE  command,  the  symbol  parameters  generated  by  the 
create  function  (201)  are  stored  in  the  symbol  library  by 
(4).  let  Symbol  Parameters  Prom  Library  (3)  generates  an 
error  message  (301)  if  the  index  inputted  by  the  user  is 
not  in  the  library.  Similarly,  Perform  Library  Addition 


N o d e : A1 4 


Figure9.  Perform  Display  Function 


4.14  Text . Process  liter  Function  (1)  checks  the  va- 


lidity of  the  alter  command  parameters  and  produces  an  er- 
ror message  (101)  if  the  parameters  are  illegal,  /liter 
commands  with  valid  parameters  (102,  103,  104  , 105)  are 
passed  to  the  appropriate  module  which  generates  the  neces- 
sary parameter  modifications  (201,  301,  401,  501).  The  pa- 
rameter modif i-eations  (601,  602,  60  3,  604)  are  used  by 
Drive  Display  (6)  to  manipulate  the  display  output  (601). 


I Responses 


Text.  After  the  subject  has  entered  his  ID  infor- 
mation ("'Cl),  Do  Experiment  Secuence  (?)  displays  a sti- 


mulus ( ’01)  according  to  the  set-up  parameters  (sC2).  The 
stimulus  characteristics  ( 02)  and  subject  responses  (’;0l) 
are  passed  to  Record  Results  (4)  v.’hich  produces  the  experi- 
ment results  (401). 


’ Text . Get  Acknowledgement  Symbol  (1)  uses  the 
set-ue  parameters  ( 10  ? ) to  out  out  the  acknowledgement  sym- 
bol characteristics  (101)  ■ nu  informs  Generate  I.iasks  ( .:) 
that  the  symbol  has  been  displayed  (?C1) . Generate  Masks 
(1)  outputs  the  mask  characteristics  (?01)  and  informs  ( 
that  the  mask  has  been  displayed  (301).  Generate  Stimulus 
(?)  then  outputs  the  stimulus  characteristics  (01)  based 
on  the  set-uo  parameters  (?C?). 
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A3  Text . Determine  Function  (1)  receives  the  user 
analysis  commands  (101)  and  passes  the  commands  to  the  ap- 
propriate module.  Load  Data  (2)  inputs  the  experiment  re- 
sults (211,  212)  and  passes  them  to  (3).  Generate  Confur 
sion  Matrix  (3)  produces  the  confusion  matrix  (301)  based 
on  the  user  commands  (302).  The  confusion  matrix  (301)  is 
then  outputted  or  it  is  passed  to  (4),  depending  on  the 
user  commands  (302).  Perform  Collapsing  Routine  (4)  in- 
puts the  predictor  matrix  (411)  and  produces  the  desired 
results  (401)  based  on  the  user  commands  (402). 
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Node : D-0 


Figure  14.  Perception  Experiment  Data  (Context) 


D 2 Text . The  Symbol  Library  (1)  is  created  from  user 
library  commands  (111).  The  library  (l)  can  be  accessed 
to  output  the  index  table  (101 ) or  to  output  a symbol 
(102).  The  develop  stimulus  list  activity  (103)  gets  the 
symbol  parameters  for  the  stimulus  list  from  (1). 

Experiment  Set-Up  Data  (?)  is  produced  by  user  com- 
mands (?I1)  and  the  develop  stimulus  list  activity  ( ’ll) 
or  from  the  loading  of  bulk  set-up  parameters  (313).  The 
validity  of  these  inputs  is  checked  (201)  before  the  inputs 
are  entered  into  (_).  The  Experiment  Set-Up  Data  (?)  c .n 
be  modified  by  user  commands  (21  ) or  it  can  be  accessed 
to  output  specific  entries  (201)  which  it  contains.  The 
performance  of  an  experiment  (20?)  also  uses  (?)  to  control 
the  experiment. 

The  Experiment  Data  (3)  is  created  by  the  performance 
of  an  experiment  (311)  or  from  loading  bulk  experiment  re- 
sults (312).  Experiment  Data  (3)  can  be  outputted  (301) 
or  it  can  be  analysed  (302),  subject  to  the  user  commands 
(3C1)  which  are  inputted.  The  analysis  of  experiment  re- 


sults (£11)  creates  the  Analysis  Data  (£),  which  is  mani- 
pulated according  to  the  user  commands  which  are  given 
(4C2)  and  the  predictor  matrix  which  is  inputted  (4C1). 


Node : D1 


Figure  16.  Symbol  Library 


D1  T o xt . The  Symbol  Library  is  composed  of  the  Sym- 
bol Index  T-'.ble  (l)  and  the  Symbols  (9).  The  oarameters 
associated  with  a STORE  command  are  used  to  make  entries 
into  (l),  subject  to  the  validity  of  the  inputted  index 
(1C?).  The  LIST  command  (1C1)  and  the  index  validity 
(1C?)  are  used  to  control  the  outoutting  of  the  index  ta- 
ble (101). 

The  store  symbol  activity  (?C1)  uses  (I)  to  control 
the  entry  into  (2)  of  symbol  parameters  associated  with 
a CREATE  command  ( 211).  The  DISPLAY,  PURGE  and  STIMULUS 
LIST  commands  constrain  the  use  of  (?)  to  create  a stimu- 
lus list  (201),  output  a symbol  (202)  or  to  purge  a sym- 
bol (203).  Purging  a symbol  (?03)  causes  the  contents  o1" 
(2)  to  be  modified  (312). 
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Check  if 

Symbol  
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Figure  17.  Experiment  Set-Up  Data 


Dr?  Text . The  Stimulus  List  (1)  is  created  by  the  ST  I 


I-1ULU3  LIST  command  (ill)  or  by  the  loading  of  bulk  para- 
meters (112),  subject  to  the  existence  of  the  stimulus 
(101)  in  the  fjymbol  library.  The  Stimulus  List  (1)  can  be 
outputted  (101)  or  it  can  be  used  by  the  yet  stimulus  ecti 
vity  (102)  during  the  performance  of  an  experiment.  The 
get  stimulus  activity  is  controlled  by  the  stimulus  list 
modifications  (which  can  remove  a symbol  from  the  stimulus 
list)  and  by  the  redisplay  option  (102). 

Symbol  Display  Dynamics  Parameters  ( ) are  ere  .ted  by 
the  01 3PL AY  DYNAMIC 3 command  (i'll)  or  by  the  loading  of 
bulk  parameters  (ill).  The  contents  of  (2)  can  be  output- 
ted (201)  or  it  can  be  used  to  display  a stimulus  (202) 
during  the  performance  of  an  experiment,  subject  to  the 
constraint  of  the  get  stimulus  activity  ( 20 1 ) , and  the  sti 
mulus  time  (202). 

The  Mask  Characteristics  (3)  are  created  by  the  ??A3K 
command  (311)  or  by  the  loading  of  bulk  set-up  oar _ mete~s 
(312).  Mask  characteristics  (3)  are  used  to  display  masks 
(302)  during  an  experiment  (according  to  the  mask  times 
(301))  or  they  can  be  outputted  (301). 

Time  Parameters  (4)  are  produced  by  loading  bulk  pa- 
rameters (412)  or  from  user  commands.  The  parameters  can 
be  outputted  (401)  or  they  can  be  used  to  control  the  use 
of  (?)  and  ( 3 ) . 

The  Display  Sequence  Parameters  (5)  are  used  to  modi- 
fy tho  stimulus  list  (1)  or  to  constrain  the  get  stimulus 
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Print  Request  ID 


Figure  18.  Experiment  Data 


D3  Text ♦ ID  Information  (l)  is  produced  by  the  sub- 
ject innuts  (ill)  after  the  information  has  been  requested 
(1C’).  This  data  (1)  is  outputted  (111)  if  this  is  speci- 
fied by  the  print  option  (1C1). 

The  displayed  stimulus  (•)  is  created  by  the  get  sti- 
mulus activity  (nIl)  and  is  modified  according  to  the  sym- 
bol display  dynamics  ( ?C  ) . The  stimulus  index  .and  modifi- 
cations (2)  are  outputted  (101)  according  to  the  int  op- 
tion ( °G1 ) . 

The  Subject  Response  (3)  is  created  by  the  subject  re- 
sponding to  a displayed  stimulus  (311).  This  data  (3)  is 
outputted  (301)  when  specified  by  the  print  option  (4C1). 
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Generate  Node  : D4 

Confusion 

Matrix 


Figure  19.  Analysis  Data 


Ql,  Text.  Confusion  Matrices  (l)  are  created  by  the 


generate  confusion  matrix  activity  (1C1)  which  usee  the 
experiment  results  (111).  The  resulting  confusion  matrix 
(1)  can  be  outputted  (101)  or  it  can  be  manipulated  by  the 
performance  of  a collapsing  routine  (102)  to  produce  ( . 

The  Predictor  Matrix  (2)  is  loaded  (211)  subject  to 
the  user  CNT5R  command  (2C1).  This  data  is  also  used  in 
performing  a collapsing  routine  ( J01)  to  produce  (3). 

The  performance  of  a collapsing  routine  using  (1)  and 
( ) Produces  the  Collapsed  Data  (3)  according  to  the  option 
specified  by  the  predictor  command  (3C1). 


Summary 

This  chapter  has  presented  the  functional  model  of 
the  system,  which  is  the  basis  of  the  software  design  pre- 


sented in  Chapter  iV. 


IV.  design 


Introduce  tern- — 

The  purpose  of  the  de3Tan~trire&e^in  <a  development  pro- 
ject is  to  definitizo  the  functions  end  operations~riebTas — 
sary  to  satisfy  the  system  requirements.  As  discussed  in 
Chapter  I,  this  investigation  does  not  present  a complete 
design  phase.  Rather,  the  intent  is  to  design  the  soft- 
ware stricture  which  '..ill  be  used  in  implementing  the  sys- 
tem. 


The  approach  which  is  used  in  this  investigation  is 
called  structured  design  (Ref  5).  This  design  method  at- 
tempts to  reduce  software  complexity  to  make  coding,  de- 
bugging and  modification  easier,  faster  and  less  expensive. 
The  symplicity  of  the  design  which  is  developed  is  enhanced 
by  dividing  the  software  into  separate  pieces  (modules ) in 
such  a way  that  modules  can  be  implemented  and  modified 
with  minimal  consideration  or  effect  on  the  other  parts  of 
the  system. 

The  remainder  of  this  chapter  uses  a graphical  tool 
called  structured  charts  (Ref  7:547-5^7)  to  present  the 
software  structural  design  which  was  developed.  The  inter- 
faces between  the  modules  of  the  design  are  also  given,  to- 
gether with  a functional  description  of  each  module.  /here 
appropriate , the  module  descriptions  point  out  any  anti- 
cipated problems  which  may  be  encountered  in  implementing 
the  module. 
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Structure  Charts 

The  structure  charts  for  the  complete  software  design 
are  shown  in  Figures  20  thru  23 • These  figures  present  the 
structure  of  the  system  executive,  together  v/ith  the  struc- 
ture of  each  of  the  system’s  three  basic  modes  of  opera- 
tions (Set-Up,  Experiment  Execution  and  Dat  . Analysis). 

'The-f'jQll owing  sections  of  this  chanter  discuss  the  dot  >ils 
of  each  Part  of  tHe— eaftware  structure. 


1 

2 

3 

A 


set-up  command 
set-up  parameters 
experiment  results 
error  messages 


Interface 
IN  OUT 

system  commands 
set-up  parameters 
experiment  results 
analysis  results 


Figure  20.  System  Executive  Structure 


System  Executive . /hen  the  system  is  initiated,  the 
SYSTEM-EXECUTIVE  outputs  a message  to  the  user  stating  that 
the  system  is  executing  the  executive,  and  requesting  the 
user  to  input  the  desired  mode  of  operation.  If  the  user 
responds  with  any  input  other  than  SET-U1 , EXPERIMENT  EXE- 
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Figure  22.  Structure  of  Experiment  Execution  Mode 


Figure  23.  Structure  of  D.v.ta  An -.lysis  Hole 


GUT  I OK  or  GAT  A ANALYSIS,  the  executive  v/ill  output  an  er- 
ror message  and  request  the  user  to  reenter  the  operation 
mode.  /hen  a valid  operation  mode  is  inputted,  the  SYS- 
TEM-EXECUTIVE ill  invoke  (call)  either  the  SET-UP-EXECU- 
TIVE, the  EXPERIMENT -EXECUTION-EXECUTIVE  or  the  DAT A- ANALY- 
SIS-EXECUTIVE, depending  on  the  'user  input. 


The  CONSOLE-INPUT  and  CONSOLE-OUTPUT  modules  consist 
of  the  routines  necessary  to  control  I/O  bet  . sen  the  user 
terminal  and  the  system,  while  the  system  is  executing  the 
SYSTEM-EXECUTIVE.  It  is  anticipated  that  most  of  the  re- 
quired routines  v/ill  be  included  in  the  operating  system 
or  other  software  which  is  obtained  with  the  hardware  sys- 
tem. The  SET-UP-EXECUTIVE , EXPERIMENT-EXECUTION-EXECUTIVE 
and  DAT  A- ANALYST  S -EXEC  UT I VE  are  discussed  separately  brio  . 
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dot— Un  Mode.  ./hen  invoiced,  the  SMT-UP-MMEGUTIVE  (Pi 
'4)  outputs  a message  to  the  user  informing  him  that 
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TIVE  if  the  user  enters  the  END  SET-UP  command.  If  the 
user  enters  the  LIBRARY  command,  the  SET-UP -EXECUTIVE  pis- 
ses control  of  the  system  to  the  LIBRARY-EXECUTIVE.  For 
any  of  the  other  commands  in  Table  I,  the  H ANDL E-SET -UP - 
PARAMETKR3  module  is  invoked. 

.then  a Set-Up  mode  nodule  requires  an  I/O  operation, 
an  identifier  for  the  I/O  device  is  passed  to  the  SET-UP- 
INPUT  or  SET-UP-OUTPUT  modules.  In  the  case  of  an  output 
operation,  the  data  to  be  outputted  is  also  passed  to  the 
3ET-UP-0UTPUT  module.  The  SET-UP-INPUT  and  SET-UP-OUTPUT 
modules  then  invoke  the  appropriate  subordinate  modules  to 
perform!  the  I/O  operation.  The  subordinate  modules  con- 
tain the  I/O  handlers  for  the  particular  device  they  con- 
trol. The  DISPLAY-OUTPUT  module  will  manipulate  the  con- 
tents of  a buffer  whose  contents  will  be  continuously 
mapped  onto  the  disolay  device  by  a h rdware  display  dri- 
ver. 

The  LIBRARY-EXECUTIVE  (Figure  23)  is  invoked  when  the 
SET-UP-EXECUTIVE  receives  the  LIBRARY  command  from  the 
user.  The  LIBRARY-EXECUTIVE  responds  by  requesting  the 
user  to  choose  one  of  the  following  options:  Create, 

Store,  Display,  Purge,  Alter,  List  or  End.  If  the  user  re- 
quests any  other  function,  the  LIBRARY-EXECUTIVE  will  out- 
put an  error  message  and  repeat  the  request.  If  the  user 
enters  the  END  function,  the  LIBRARY-EXECUTIVE  will  return 
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subordinate  module,  and  passes  to  that  module  any  func- 
tion parameters  which  have  been  inputted. 

For  the  CREATE  command,  the  LIBRARY-EXECUTIVE  invokes 
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Figure  25.  Library  Mode  Executive 


the  CREATE  module.  The  CREATE  module  and  its  subordinates 
(Figure  26)  allow  the  user  to  enter  the  parameters  which 
define  a symbol,  and  to  output  that  symbol  on  the  display 
as  it  is  being  created.  /hen  invoked,  the  CREATE  module 
checks  to  determine  if  the  user  has  entered  any  parameters 
with  the  CREATE  command.  If  no  parameters  have  been  en- 
tered, the  GET-PARAMETER  modul°  is  called  to  request  the 
user  to  enter  a parameter.  Only  one  parameter  is  passed 
to  the  VALIDATS-PARAMETER  module  each  time  it  is  called, 
so  if  the  user  has  entered  a series  of  parameters,  the  VA- 
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LI DATE-PARAMETER  module  .-/ill  be  invoked  once  for  each  Tiara- 


If  a oarameter  is  invalid,  the  VALI 
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Figure  ?6.  Create  Module  and  Subordinates 


DATE-PARAMETER  module  returns  an  error  message 


A valid  CREATE  command  parameter  i 


VERT-TO-INTERNAL-FORM  module.  Although  the  exact 


ymbol 


entation  -which  will  be  used  is  not  kno  -n,  it  is  as 


used  that  the  user  input 


.vill  have  to  be  converted  to  a 


different  form  to  b 


used  by  the  DISPLAY-OUTPUT  modul 


to  be  stored  in  the  symbol  library.  The  converted  parame 


ter  is  passed  to  the  DISPLAY-OUTPUT  module  and  to  the  TEM- 


PORARY-STORE module 


The  TEMPORARY-STORE  module 


the  individual 
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converted  CREATE  parameters  to  define  a complete  symbol 


The  accumulated  parameters  (called  Symbol  Data)  are  x ~eated 
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as  an  abstract  data  type  (discussed  in  the  last  section  of 
this  chapter).  Abstract  data  types  use  the  "information 
hiding"  approach  by  considering  a data  structure  and  its 
accessing  and  modifying  procedures  as  a separate  module 
(Ref  2:1056).  Thus,  the  TEMPORARY-STORE  module  invokes  the 
TEMPORARY-SYMBOL-STORE  module  (Figure  40)  and  passes  it 
the  symbol  parameters  which  are  to  be  added  to  the  data 
structure . 

After  all  of  the  CREATE  command  parameters  have  been 
processed,  the  CREATE  module  invokes  the  GET -PARAMETER  mo- 
dule and  repeats  the  series  described  above.  If  the  user 
enters  the  CLEAR  command,  the  CLEAR  module  is  invoked  to 
clear  the  Symbol  Data  Structure  and  to  clear  the  display, 
in  preparation  for  defining  a new  symbol.  When  the  END 
command  is  entered,  control  is  returned  to  the  LIBRARY-EXE- 
CUTIVE. 

The  STORE  module  is  called  by  the  LIBRARY-EXECUTIVE 
when  the  user  enters  the  STORE  command.  The  purpose  of 
this  module  and  its  subordinates  (Figure  27)  is  to  allow 
the  user  to  enter  into  the  symbol  library  a symbol  which 
has  been  defined  using  the  CREATE  function.  When  the 
STORE  module  is  invoked,  it  first  checks  to  determine  if 
the  user  has  entered  an  index  for  the  symbol.  If  an  index 
has  not  been  inputted,  the  GET-INDEX  module  is  invoked  to 
request  the  user  to  enter  an  index.  After  the  index  has 
been  inputted,  the  STORE-SYMBOL-PARAMETERS  module  is 
called.  This  module  invokes  the  TEMPORARY-SYMBOL-STORE 
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Figure  27.  Store  Module  and  Subordinates 


module  (Figure  40)  to  retrieve  the  Symbol  Data.  The  Sym- 
bol Data  and  index  are  then  passed  to  the  LIBRARY-MANIPU- 
LATION  module  (Figure  41)  to  add  the  index  and  Symbol  Data 
to  the  symbol  library.  (The  symbol  library  and  its  index 
table  are  treated  as  an  abstract  data  type).  If  the  LI- 
BRARY-MANIPULATION module  returns  an  indicator  that  the 
index  is  already  in  use,  the  STORE-SYMBOL-PARAMETERS  mo- 
dule will  return  a message  to  the  user  indicating  that  the 
STORE  operation  was  not  performed. 

When  the  user  wants  to  display  a symbol  that  is 
stored  in  the  symbol  library,  he  inputs  the  DISPLAY  com- 
mand to  the  LIBRARY-EXECUTIVE.  The  LIBRARY-EXECUTIVE  then 
invokes  the  DISPLAY  module  (Figure  28),  which  checks  if  the 
user  has  inputted  a symbol  index.  If  an  index  has  not  been 
inputted,  the  GET-INDEX  module  is  called  to  output  a mes- 
sage to  the  user  requesting  that  an  index  be  inputted.  The 


index  is  passed  to  the  GET-SYMB0L-PARAK3TERS  module  which 
uses  the  LIBRARY-MANIPULATION  module  (Figure  41)  to  fetch 
the  symbol  parameters  from  the  library.  If  the  LIBRARY- 


Figure  28.  Display  Module  and  Subordinates 


MANIPULATION  module  returns  an  indicator  that  the  index  was 
not  found  in  the  library,  the  GET-3YMB0L-PARAMETERS  module 
outputs  an  error  message  to  the  user.  The  symbol  para- 
meters are  passed  to  the  SET-UP-OUTPUT  module,  which  dis- 
plays the  symbol . 

The  LIBRARY-EXECUTIVE  invokes  the  PURGE  module  (Fi- 
gure 29)  when  the  user  enters  the  PURGE  command.  This 
module  checks  to  determine  if  the  user  has  entered  an  in- 
dex, and  if  he  has  not,  the  GET-INDEX  module  is  called  to 
output  a request  for  an  index.  The  index  is  passed  to  the 
DELETE-SYMBOL  module  which  passes  the  index  and  a purge 
function  to  the  LIBRARY-MANIPULATION  module  (Figure  41). 

If  the  index  is  not  in  the  library,  the  DELETE-SYMBOL  mo- 
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dule  returns  an  error  message  to  the  user. 

If  the  user  wants  to  test  the  effects  of  symbol  dis- 
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Figure  29.  Purge  Module  and  Subordinates 


play  dynamics  on  the  symbol  which  is  currently  being  dis- 
played, he  inputs  the  ALTER  command  to  the  LIBRARY-EXECU- 
TIVE, which  invokes  the  ALTER  module  (Figure  30).  The  AL- 
TER module  checks  if  an  alter  function  has  been  inputted, 
and  calls  the  GET-VALID-FUNCTION  module  to  output  a re- 
quest to  the  user  if  a function  has  not  been  inputted.  The 
GET-VALID-FUNCTION  module  calls  VALI DATE-FUNCTION  to  check 
if  a legal  function  has  been  inputted,  and  returns  an  er- 
ror message  if  the  function  is  invalid. 

After  a valid  function  has  been  inputted,  the  GET-VA- 
LID-FUNCTION  module  requests  the  user  to  enter  the  function 
parameters,  and  invokes  the  CHECK-SYMBOL-DISPLAY-DYNAMICS- 
PARAMETERS  to  determine  if  the  parameters  are  legal.  If 
the  parameters  are  ii.-„  .*al,  GET-VALID-PARAMETERS  requests 
the  user  to  reenter  the  parameters. 
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Figure  30.  Alter  Module  and  Subordinates 


When  the  user  has  entered  a legal  function,  with  va- 
lid parameters,  the  PBRFORM-FTJNCTION  module  is  invoked, 
which  in  turn  calls  the  appropriate  subordinate  module  to 
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perform  the  function.  The  PERFORM-ROTATE,  PERFORM-ADD/ 
DELETE,  PERFORM-JITTER  and  PERFORM-VIBRATE  modules  then 
output  the  display  driver  code  to  manipulate  the  display 
to  perform  the  function. 

After  an  alter  function  has  been  processed,  the  ALTER 
module  repeats  the  above  sequence,  thus  allowing  the  user 
to  perform  a combination  of  functions  simultaneously.  The 
ALTER  module  continues  to  request  and  process  alter  func- 
tions until  the  END  ALTER  command  is  inputted,  which  dis- 
continues the  alter  function  operations  and  returns  con- 
trol to  the  LIBRARY-EXECUTIVE. 

The  PERFORM-ROTATE,  PERFORM-ADD/DELETE , PERFORM-JIT- 
TER and  PERFORM-VIBRATE  modules  handle  the  operations  dis- 
cussed in  Chapter  II.  The  algorithms  which  must  be  per- 
formed by  the  modules  have  not  been  investigated,  primarily 
because  the  hardware  drivers  which  will  be  used  have  not 
been  defined.  Although  each  alter  function  is  represented 
by  a single  module,  these  modules  are  very  complex,  requir- 
ing many  subordinate  modules  for  each  function.  In  addi- 
tion, the  problems  associated  with  performing  simultaneous 
functions  have  not  been  investigated. 

The  final  library  command  to  be  discussed  is  the  LIST 
command.  This  command  has  options  to  output  the  number  of 
symbols  in  the  symbol  library  or  to  output  the  indexes  of 
the  symbols  in  the  symbol  library.  When  the  LIST  command 
is  inputted,  the  LIBRARY-EXECUTIVE  invokes  the  LIST  module 
(Figure  31),  'which  checks  if  the  user  has  inputted  an  op- 
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tion.  The  LIST  module  invokes  the  GET-NUMBER-OF-SYMBOLS 
or  GET -INDEX-TABLE  module  depending  on  the  chosen  option, 
or  returns  an  error  message  if  an  invalid  option  is  cho- 


Figure  31.  List  Module 


sen.  The  GET-NUMBER-OF-SYMBOLS  and  GET-INDEX-TABLE  both 
use  the  LIBRARY-MANIPULATION  module  (Figure  41)  to  per- 
form their  functions. 

The  HANDLE-SET -UP-PARAMETERS  module  (Figure  31)  is 
invoked  when  the  user  enters  a command  from  Table  I other 
than  LIBRARY  or  BNP  SET-UP.  This  module  and  its  subordi- 
nates validate  and  store  the  set-up  parameters  which  will 
be  used  during  the  execution  of  an  experiment,  and  perform 
the  set-up  parameters  functions. 

For  a command  other  than-  SET -UP -PAR AMETERS , the  VALI- 
DAT E-PARAMETERS  module  is  invoked.  This  module  first  de- 
termines if  the  user  has  entered  the  parameters  for  the 
command.  If  the  parameters  have  not  been  entered,  the 
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Figure  32.  Handle  Set-Up  Parameters  Module 


GET-PARAMETERS  module  is  called  to  request  the  user  to  in- 
put the  parameters.  The  command  and  parameters  are  passed 
to  the  CHECK-FOR-SRRORS  module.  This  module  invokes  the 
appropriate  subordinate  module  to  validate  the  command  pa- 
rameters . 

Valid  set-up  parameters  are  treated  as  an  abstract  da- 
ta type  (called  Current  Set-Up  Parameters)  as  discussed  at 
the  end  of  this  chapter.  The  valid  commands  and  parameters 
are  passed  to  the  STORE-PARAMETERS  module  which  invokes  the 
SET-UP -PARAMBTERS-MANIPULATION  module  to  enter  the  parame- 
ters into  the  Current  Set-Up  Parameters  data  structure. 

The  CHECK-STIMULUS-LIST -PARAMETERS  module  uses  the 
LIBRARY-MANIPULATION  module  to  check  that  the  indexes  which 
are  inputted  for  the  stimulus  list  are  contained  in  the 
symbol  library.  At  this  point  in  the  design  it  has  not 
been  determined  if  the  stimulus  list  will  only  contain  the 
indexes  for  the  symbols,  with  the  appropriate  parameters 
being  retrieved  from  the  symbol  library  when  the  stimulus 
is  needed. 

As  discussed  in  Chapter  II,  the  system  is  required  to 
generate  and  store  static  masks  before  beginning  execution 
of  an  experiment.  Thus,  CHECK-3TATIC-PARAMBTERS  invokes 
the  GENERAT E-STATIC -MASKS  module  if  the  mask  parameters 
are  valid,  and  this  module  produces  the  masks.  The  static 
masks  are  then  passed  to  the  STORE-PARAMETERS  module  which 
enters  the  masks  into  the  Current  Set-Up  Parameters  data 
structure . 
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The  PERFORM-SET-UP -FUNCTIONS  module  and  its  subordi 
nates  (Figure  33)  execute  the  SET  UP  PARAMETERS  commands 
which  were  discussed  in  Chapter  II.  V/hen  this  module  is 


2 


invoked  by  the  HANDLE-SET -UP -PARAMETERS  module,  it  first 
checks  if  the  user  has  inputted  a command  option.  If  an 
option  has  not  been  entered,  GET-OPTION  is  invoked  to  out- 
put a request  to  the  user. 

The  STORE  module  is  called  if  the  user  chooses  the 
STORE  option.  This  module  and  it3  subordinates  store  the 
Current  Set-Up  Parameters  in  permanent  storage.  When 
called,  the  STORE  module  checks  if  the  user  has  entered  an 
index  and  uses  the  GET-INDEX  module  to  request  an  index  if 
one  has  not  been  entered.  The  index  is  passed  to  the  VA- 
LIDATE-STORE-INDEX  module  which  determines  if  the  index 
is  not  already  in  use  (this  will  probably  be  done  using 
operating  system  file  management  routines).  If  the  index 
is  invalid,  an  error  message  is  outputted  to  the  user.  For 
a valid  index,  the  STORE-BULK-SET-UP -PARAMETERS  module  is 
invoked  to  store  the  parameters  in  a permanent  file  (again 
using  operating  system  routines). 

If  the  user  enters  the  SET-UP  PARAMETERS  print  option, 
the  PRINT  module  is  invoked.  This  module  uses  the  SET-UP- 
PARAMETERS-KANIPULATION  module  to  output  the  Current  Set- 
Up  Parameters  to  the  printer.  The  RELOAD  and  ERASE  modules 
recall  and  purge  set-up  parameters  which  were  saved  using 
the  STORE  option.  Both  of  these  modules  (and  their  subor- 
dinates) function  in  a manner  similar  to  the  STORE  module: 
they  check  if  an  index  has  been  inputted,  validate  the  in- 
dex and  then  the  operation  is  performed  using  operating 


system  routines.  In  addition,  the  RELOAD  module  uses  the 


oET— UP— PARAMETERS— MANIPULATION  module  to  enter  the  re- 
trieved parameters  into  the  Current  Set-Up  Parameters  data 
structure . 

Experiment  Execution  Mode.  When  the  user  wants  to  ex- 
ecute an  experiment,  he  inputs  the  EXPERIMENT  EXECUTION 
command  to  the  SYSTEM-EXECUTIVE,  which  then  invokes  the 
EXPERIMENT-EXECUTION-EXECUTIVE  (Figure  34).  This  module 
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Figure  34.  Experiment  Execution  Executive  and  Subordinates 


outputs  a message  to  the  user  stating  that  the  system  is 
in  the  Experiment  Execution  mode.  The  PERFORM-EXPERIMENT 
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module  is  then  called  to  handle  execution  of  the  experi- 
ment. While  the  system  is  in  the  Experiment  Execution 
mode,  the  CONSOLE-INPUT  and  EXPERIMENT-OUTPUT  modules  ma- 
nage the  system  I/O. 

In  addition  to  user  messages,  the  EXPERIMENT-OUTPUT 
module  is  also  passed  the  experiment  results,  which  con- 
sists of  the  stimulus  displayed,  subject  response  and  sub- 
ject response  time  information.  This  information  is  passed 
from  the  P ERF ORM- EXPERIM ENT  module  to  the  EXPERIMENT-OUTPUT 
module  for  each  stimulus  displayed  during  the  experiment. 
The  EXPERIMENT-OUTPUT  module  passes  the  experiment  result 
information  to  the  MASS-STORAGE  module  and  to  the  PRINTER- 
OUTPUT  module  (if  this  option  is  specified  in  the  set-up 
parameters) . 

When  the  PERFORM-EXPSRIMENT  module  (Figure  35)  is  in- 
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voked,  it  calls  the  GET-ID  module  to  request  the  subject 
to  input  ID  information  (name,  date,  etc.)*  This  request 
will  be  displayed  on  the  console  until  the  ID  information 
is  entered,  or  the  Experiment  Execution  mode  is  termi- 
nated by  inputting  the  END  EXPERIMENT  MODE  command.  After 
the  subject  enters  the  ID  information,  the  PERFORM-EXPERI- 
MSNT-SEQUENCE  module  is  invoked.  This  module  controls  the 
experiment  until  the  subject  enters  the  STOP  command,  at 
which  time  the  END-EXPERIMENT  module  will  be  invoked  to 
output  an  "end  of  experiment"  message.  The  GET-ID  module 
will  then  be  invoked  again,  and  the  above  sequence  will  be 
repeated  for  the  next  subject. 

The  PERFORM-EXPERIMENT-SEQUENCE  module  and  its  subor- 
dinates (Figure  36)  use  the  set-up  parameters  (which  were 
created  in  the  Set-Up  mode)  to  control  the  experiment. 

These  modules  all  have  access  to  the  Current  Set-Up  Para- 
meters data  by  using  the  3ET-UP-PARAMETERS-MANIPULATI0N  mo- 
dule which  is  discussed  at  the  end  of  this  chapter. 

When  invoked  by  the  PERPORM-EXPERIMENT  module,  the 
PERFORM-EXPERIMENT-SEQUENCE  module  calls  the  ACKNOWLEDGE- 
MENT-SYMBOL module  to  output  the  acknowledgement  symbol, 
indicating  that  the  experiment  sequence  is  about  to  begin. 
The  MASKS  module  is  then  called  to  output  the  first  mask. 
The  MASKS  module  and  its  subordinates  recall  the  stored 
static  masks  or  generate  dynamic  masks,  depending  on  the 
set-up  parameters. 

After  the  first  mask  is  displayed,  the  STIMULUS  mo- 
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the  subject’s  response  and  response  time  (by  invoking  COM- 
PUT  E-RESPONS  E-TIME  ) , and  to  make  changes  to  the  stimulus 
list  according  to  the  set-up  parameters  (by  calling  MODI- 
PY-3TIMULU3-LIST) . The  ACKNOWLEDGEMENT-SYMBOL  module  is 
then  invoked  to  begin  the  next  display  sequence. 

The  STIMULUS  module  (Figure  37)  invokes  the  GET-STI- 
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Figure  37.  Stimulus  Module  and  Subordinates 


MULUS  module,  which  checks  the  set-up  parameters  to  deter- 
mine the  algorithm  to  use  for  selecting  a stimulus  from  the 
stimulus  list.  The  ORDER BD-LIST  or  RANDOM-LIST  module  is 
then  invoked  to  choose  the  stimulus.  The  stimulus  is 
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passed  to  the  STIMULUS-MODIFICATIONS  module.  This  module 
checks  the  set-up  parameters  to  determine  which  symbol  dis- 
play dynamics  should  be  performed. 

Although  the  algorithm  to  be  used  by  the  RANDOM-LIST 
module  (to  select  a stimulus  from  the  stimulus  list)  has 
not  been  developed,  this  module  should  not  be  difficult  to 
implement.  However,  as  mentioned  previously,  the  ROTATE, 
ADD/DELETE,  JITTER  and  VIBRATE  modules  will  probably  be 
very  complex  and  the  problems  associated  with  performing 
simultaneous  display  dynamics  functions  have  not  been  inves- 
tigated. 

Data  Analysis  Mode . The  Data  Analysis  mode  allows  the 
user  to  perform  data  reduction  operations  on  experiment  re- 
sults. '/hen  the  user  inputs  the  DATA  ANALYSIS  command  to 
the  SYSTEM-EXECUTIVE,  the  DATA-ANALYSIS-EXECUTIVE  (Figure 
38)  is  invoked.  This  module  then  outputs  a message  to  the 
user  informing  him  that  the  system  is  in  the  Data  Analysis 
mode.  The  ANALYSIS-INPUT  module  handles  the  input  opera- 
tions for  the  analysis  mode.  vVhile  in  the  Data  Analysis 
mode,  the  system  receives  user  commands  from  the  console 
(handled  by  the  CONSOLE-INPUT  module)  and  also  inputs  ex- 
periment results  and  predictor  matrices  (handled  by  the 
BULK-INPUT  module)  as  discussed  in  Chapter  II.  Outputs 
from  the  Data  Analysis  mode  are  handled  by  the  ANALYSIS- 
OUTPUT  module.  These  outputs  consist  of  reo.uests  to  the 
user  and  bulk  outputs  which  are  handled  by  the  CONSOLE  and 
PRINTER  modules,  respectively. 
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Figure  38.  Data  Analysis  Executive 


After  the  D AT A-ANALY3I 5-EXECUTIVE  has  informed  the 
user  of  the  system  operation  mode,  it  invokes  the  PERFORM- 
ANALYSI3  module  (Figure  39).  This  module  invokes  the  LOAD- 
DATA  module  which  requests  the  user  to  input  the  ID  for  the 
experiment  results  to  be  analysed.  The  LOAD-DATA  module 
then  retrieves  the  appropriate  experiment  results.  The 
CONFUSION-OPTION  module  is  then  invoked. 

The  CONFUSION-OPTION  module  requests  the  user  to  in- 
put the  function  to  be  performed,  and  returns  an  error  mes- 
sage if  an  invalid  input  is  given.  The  CONFUSION-OPTION 
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Figure  39.  Perform  Analysis  Module  and  Subordinates 


module  then  calls  the  appropriate  subordinate  module  to 
perform  the  desired  function.  These  subordinate  modules 
contain  the  routines  to  generate  the  confusion  matrices 
discussed  in  Chapter  II.  If  the  user  inputs  the  PRINT  com- 
mand, the  generated  confusion  matrix  is  outputted  to  the 
printer. 
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If  the  user  enters  the  PREDICTOR  command,  the  PREDIC- 
TOR-OPTION module  is  invoked.  This  module  invokes  the  GET- 


PREDICTOR-MATRIX  module  to  request  the  user  to  input  a pre- 
dictor matrix.  After  the  predictor  matrix  is  inputted,  the 
PREDICTOR-OPTION  module  requests  the  user  to  input  the  type 
of  collapsing  routine  to  be  performed,  and  the  associated 
parameters.  The  RANK-COLLAPSE  or  ABSOLUTE-DISTANCE-COLLAPSE 
module  is  called  to  perform  the  collapsing  routine  and  out- 
put the  results. 

Abstract  Data  Types.  This  section  presents  the  struc- 
ture charts  and  descriptions  of  the  abstract  data  types  in- 
troduced in  the  preceding  sections.  An  abstract  data  type 
combines  the  data  structure  and  its  accessing  and  modifying 
modules  so  that  all  the  operations  on  the  data  structure 
are  performed  through  a single  module. 

The  three  abstract  data  types  used  in  this  design  are 
the  Symbol  Data,  the  Symbol  Library  and  the  Current  Set-Up 
Parameters.  Symbol  Data  contains  the  symbol  parameters 
which  are  accumulated  using  the  CREATE  command  during  the 
Set-Up  mode.  The  Symbol  Library  contains  the  indexes  and 
symbol  parameters  of  the  symbols  which  the  user  has  saved 
with  the  library  mode  STORE  command.  The  Current  Set-Up 
Parameters  data  structure  contains  the  parameters  which 
are  inputted  during  the  Set-Up  mode  for  use  during  the  exe- 
cution of  an  experiment.  A summary  of  the  operations  (and 
the  corresponding  input  parameters)  which  can  be  performed 
on  the  abstract  data  types  appears  in  Table  II. 
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Table  II 

ABSTRACT  DATA  TYPE  OPERATIONS 
Symbol  Data 

OPERATION  REQUIRED  INPUT  PARAMETERS 

Add  symbol  parameters 

Fetch  

Clear  


Symbol  Library 

OPERATION  REQUIRED  INPUT  PARAMETERS 


Store 

Purge 

Recall 

Count 

Fetch 


symbol  index,  symbol  parameters 
symbol  index 
symbol  index 


Current  Set-Up  Parameters 


OPERATION 


REQUIRED  INPUT  PARAMETERS 


Add 

Fetch 

Reload 


set-up  parameters,  parameter  type 
parameter  type 
set-up  parameters 


I 

i 

I 

I 


The  Symbol  Data  is  accessed  through  the  TSMP0RARY-3YM- 
B0L-3T0RE  module  (Figure  40).  This  module  performs  three 
operations  on  the  Symbol  Data:  Add,  Fetch  and  Clear.  When 

the  TEMP0RARY-SYMB0L-3T0RS  is  called  to  perform  the  Add 
operation,  the  parameters  which  are  passed  from  the  calling 
module  are  entered  into  the  data  structure  by  the  ADD-DATA 
module.  The  Fetch  operation  is  performed  by  the  FETCH-DATA 
module,  which  returns  the  contents  of  the  data  structure 
to  the  calling  module.  The  Clear  operation  allows  the  cal- 
ling module  to  delete  the  contents  of  the  Symbol  Data. 

The  LIBRARY-MANIPULATION  module  and  its  subordinates 
(Figure  41)  manage  the  operations  which  can  be  performed 
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Figure  40.  Temporary  Symbol  Store  Module 
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on  the  Symbol  Library  and  its  index  table.  The  operations 
that  a calling  module  can  request  are:  Store  or  Purge  a 

symbol  index  and  corresponding  symbol  oarameters,  Recall 
the  symbol  parameters  for  a given  index,  Count  the  num- 
ber of  indexes  in  the  index  table  and  Fetch  the  index  ta- 
ble . 

For  the  Store  operation,  the  calling  program  passes 
the  symbol  index  and  symbol  parameters  to  LIBRARY-MANIPULA- 
TION. The  LIBRARY-MANIPULATION  module  invokes  the  PERFORM- 
INDEX-OPERATION  module  with  a request  that  the  index  be  ad- 
ded to  the  index  table.  PERFORM-INDEX-OPERATION  first 
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searches  the  index  table  (using  SEARCH-POR-INDEX)  and,  if 
the  index  is  found,  returns  an  error,  condition  to  LIBRARY- 
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Figure  41.  Library  Manipulation  Module 
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MANIPULATION.  If  the  index  is  not  found,  ADD-INDEX  is  in- 
voked to  enter  the  index  into  the  index  table.  Next,  LI- 


BRARY-MANIPULATION  invokes  PERFORM-SYMBOL-OPERATION  to  en- 
ter the  symbol  parameters  into  the  symbol  library  (using 
ADD-SYMBOL ) . 

The  Purge  operation  is  performed  in  a manner  similar 
to  the  Store  operation:  first  the  index  table  is  searched 

for  the  inputted  index  and  if  it  is  not  in  the  table,  an 
error  condition  is  returned.  If  the  index  is  found,  PER- 
FORM-IND EX-OPERATION  invokes  DELETE-INDEX  to  remove  the  in- 
dex table  entry.  LIBRARY-MANIPULATION  then  invokes  PERFORM- 
SYMBOL-OPERATION  to  delete  the  symbol  parameters  from  the 
library. 

To  Recall  symbol  parameters  for  a given  index,  LIBRARY- 
MANIPULATION  invokes  PERFORM-INDEX-OPERATION  to  search  the 
index  table.  If  the  index  is  found,  its  value  (the  loca- 
tion of  the  symbol  parameters)  is  returned  to  LIBRARY- 
MANIPULATION;  if  the  index  is  not  found,  an  error  condition 
is  returned.  The  index  value  is  then  passed  to  PERFORM- 
SYMBOL-OPERATION  which  uses  RETURN-SYMBOL-PARAMETERS  to 
fetch  the  parameters  from  the  library. 

When  the  calling  module  requests  a Count  of  the  num- 
ber of  indexes  in  the  table,  the  PERFORM-INDEX-OPERATION 
module  is  invoked,  which  then  invokes  COUNT-INDEXES.  The 
contents  of  the  index  table  can  be  returned  to  the  calling 
module  by  using  the  Fetch  operation.  This  operation  is  al- 
so handled  by  PERFORM-INDEX-OPERATION,  which  uses  FETCH-IN- 
DEXES to  perform  the  operation. 

The  Current  Set-Up  Parameters  data  structure  is  ma- 
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naged  by  the  SET-UP -PARAMETER3-MANIPULATI0N  module  and  its 
subordinates  (Figure  42).  These  modules  perform  the  fol- 
lowing operations:  Add  parameters  to  the  data  structure, 

Fetch  parameters  and  Reload  the  contents  of  the  data  struc- 
ture . 

When  a calling  module  wants  to  enter  new  parameters 
into  the  data  structure,  it  calls  the  SET-UP -PARAMETERS- 
MANIPULATION  module  and  requests  an  Add  operation.  SET-UP- 
PARAMETERS-MANIPULATION  invokes  the  ADD-PARAMETERS  module 
which  uses  its  subordinate  modules  to  enter  the  parameters 
into  the  data  structure.  No  error  checking  is  performed 
on  the  parameters,  and  the  new  parameters  are  written  over 
any  parameters  which  may  have  been  previously  entered. 

The  FETCH-PARAMETERS  module  is  used  to  perform  the 
Fetch  operations.  A calling  module  can  request  a particu- 
lar type  of  set-up  parameters  (e.g.,  the  stimulus  list  or 
mask  parameters)  or  it  can  request  that  all  of  the  parame- 
ters in  the  data  structure  be  returned. 

The  RELOAD-PARAMETERS  module  is  used  to  enter  an  en- 
tire set  of  set-up  parameters  into  the  data  structure.  The 
Reload  operation  is  requested  by  the  STORE-BULK-SET-UP-PA- 
RAMETER3  module  (Figure  33)  to  perform  its  function. 

Summary 

This  chapter  has  presented  the  design  of  the  system 
software  architecture  using  structure  charts.  The  func- 
tional descriptions  of  each  module  and  the  interfaces  bet- 
ween modules  was  also  presented. 


CURRENT 

SET-UP 

PARAMETERS 


Interface 


0 operation,  parans  set-up  parameters 

1 operation,  param  type  

2 operation,  param  type  set-up  parameters 

3 set-up  params  

4 stimulus  list  params  

5 time  params  

6 mask  params  

7 print  params  

8 display  sea  params  

9 display  dyn  params  

10  set-up  parameters 

11  stimulus  list  params 

12  time  params 

13  mask  params 

14  print  params 

15  display  seq  params 

16  display  dyn  params 


Figure  42.  Set-Up  Parameters  Manipulation  and  Subordinates 
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V.  RESULTS  AND  CONCLUSIONS 


Introduction 

The  purpose  of  this  chapter  is  to  discuss  the  results 
obtained  from  the  software  structure  design  and  the  con- 
clusions drawn  from  these  results. 

Results 

The  requirements  definition  for  the  Multimode  Matrix 
Display  Perception  Tests  was  accomplished  in  both  an  infor- 
mal manner  (Chapter  II)  and  in  a rigorous  manner  (Chapter 
III).  Requirements  definition  is  one  of  the  most  difficult 
and  most  important  phases  of  a development  project  (Ref  1: 
5).  The  requirements  definition  presented  in  Chapters  II 
and  III  provide  concise  and  thorough  functional  specifica- 
tions for  the  system,  which  allowed  the  development  of  the 
design  -presented  in  Chapter  IV. 

The  application  of  structured  design  techniques  re- 
sulted in  a sound  modular  design  which  will  be  easy  to  im- 
plement, modify  and  maintain.  Most  of  the  modules  in  the 
design  are  relatively  small,  allowing  the  function  of  each 
module  to  be  easily  understood.  The  use  of  abstract  data 
types  for  the  major  system  data  structures  provides  the  ca- 
pability to  make  modifications  in  the  implementation  of 
any  module  without  affecting  the  interface  to  the  data 
structure. 


89 


Conclusions 
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The  application  of  structured  analysis  and  structured 
design  techniques  during  the  early  chases  of  a development 
project  helps  to  prevent  a lot  of  problems  frequently  en- 
countered  in  the  implementation  of  a system.  Avoiding  the 
tendency  to  begin  coding  software  early  in  the  project  not 
only  results  in  a better  implementation  of  the  system,  but 
it  also  avoids  a lot  of  coding  modifications  which  might 
have  to  otherwise  be  made.  For  instance,  there  were  many 
changes  made  to  the  functional  specifications  and  design 
presented  in  this  thesis.  These  changes  were  easier  to 
make  at  this  early  stage  in  the  development  cycle,  and  they 
avoided  the  necessity  of  making  any  corresponding  changes 
in  software  code,  since  no  code  had  been  produced  at  this 
point . 

Recommendations 

When  this  thesis  was  started,  no  decisions  had  been 
made  concerning  the  hardware  which  would  be  used  to  imple- 
ment the  system.  This  caused  no  serious  problems  with 
accomplishing  the  work  in  this  thesis,  since  it  is  usually 
better  to  perform  the  requirements  definition  and  the  ini- 
tial design  phase  of  a project  and  use  the  results  of  this 
work  to  decide  on  the  best  hardware  to  use.  However,  the 
LOT  project  office  recently  ordered  a PDP-ll/45  minicompu- 
ter system  to  be  used  to  implement  the  perception  test  sys- 
tem. Therefore,  it  is  recommended  that  the  system  which 
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was  purchased  he  studied  to  determine  the  extent  to  which 
this  existing  system  can  he  used  to  directly  support  the 
perception  test  system.  For  example,  the  operating  system 
should  he  studied  to  determine  how  much  of  its  I/O  support 
can  be  used  to  implement  the  I/O  modules  described  in  Chap- 
ter IV. 

The  symbol  display  dynamics  modules  (to  perform  the 
Rotate,  Add/Delete,  Jitter  and  Vibrate  functions)  have  not 
been  specified  in  detail.  It  is  necessary  to  develop  the 
details  of  the  interface  between  these  modules  and  the  dis- 
play unit.  After  the  interface  has  been  defined,  the  algo- 
rithms for  the  symbol  display  dynamics  functions  should  be 
developed.  This  will  allow  the  design  of  the  software 
structure  to  be  completed. 

The  next  major  step  in  the  design  phase  is  to  develop 
flow  charts  for  each  of  the  modules  in  the  design.  These 
flow  charts  will  provide  a more  rigorous  specification  for 
the  modules  than  the  functional  description  presented  in 
Chapter  IV.  The  flow  charts  should  be  developed  in  enough 
detail  so  that  the  software  code  can  be  produced  from  them 
in  the  chosen  programming  language. 

Before  coding  is  started,  it  is  necessary  to  develop 
the  design  specifications  for  the  system.  These  specifi- 
cations will  consist  of  constraints  on  the  system  memory 
size,  response  time  and  other  constraints. 

It  is  recommended  that  formal  test  procedures  be  de- 
veloped. These  test  procedures  will  assure  that  the  soft- 
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v/ are  performs  as  intended  and  that  the  system  requirements 
are  met.  The  test  procedures  should  provide  for  testing 
on  the  subprogram  level  and  on  the  full  program. 


92 


r * 


r 


? 


Bibliography 


1.  Logicon,  Inc.  Management  Guide  to  Avionics  Software 

Acquisition,  Volume  I - An  Overview  of  Software  Deve- 
lopment and  Management . Dayton,  Ohio:  June  1976. 

2.  Parnas,  D.  L.,  "On  the  Criteria  to  be  Used  in  Decom- 

posing Systems  Into  Modules".  Communications  of  the 
ACM,  15:  1053-1055  (December  197?). 

3.  Ross,  D.  T.  and  K.  E.  Schoman,  Jr.  Structured  Analy- 

sis for  Requirements  Definition.  Waltham,  Massachu- 
setts: Softech,  Inc.,  April,  1976. 

4.  Softech,  Inc.  Structured  Analysis  Reader  Guide.  Wal- 
tham, Massachusetts:  May  1975. 

5.  Stevens,  W.  P.,  jet  al,  "Structured  Design".  IBM  Sys- 
tems Journal,  2:  115-139  (1974). 

6.  Teichroew,  D.  PSL/P5A  A Computer-Aided  Technique  for 

Structured  Documentation  and  Analysis  of  Information 
Processing  Systems . Ann  Arbor,  Michigan:  University 

of  Michigan,  March  1975. 

7.  Yourdon,  E.  and  L.  L.  Constantine.  Structured  Design. 

New  York:  Yordon,  Inc.,  1976. 


93 


= 


r w 

r w 


Appendix  A 

READING  STRUCTURED  ANALYSIS  DIAGRAMS 


Introduction 

This  appendix  contains  a brief  discussion  of  how  to 
read  structured  analysis  diagrams.  For  a more  detailed 
treatment  of  this  subject,  the  reader  is  referred  to  Refe- 
rence 7* 


Diagram  Syntax 


Structured  analysis  models  are  created  by  decomposing 
a subject  (in  a top-down  fashion)  into  smaller  and  smal- 
ler pieces.  The  subject  matter  is  treated  twice:  once 

from  an  activity  aspect  (activity  model)  and  once  based  on 
the  subject's  data  (data  model). 

A structured  analysis  model  consists  of  labeled  boxes 
and  arrows.  Inside  a box,  the  name  of  the  activity  (for 
an  activity  model)  or  data  item  (for  a data  model)  is  writ- 
ten. In  the  activity  case,  the  name  contains  a verb  (to 
express  action)  and  in  the  data  case  it  is  a noun  or  noun 
phrase  (to  express  a data  item). 

The  boxes  of  a diagram  are  connected  together  with  ar- 
rows, where  the  arrows  represent  interfaces  between  the 
boxes.  The  four  sides  of  a box  are  assigned  a specific 
meaning  which  defines  the  kind  of  arrow  which  may  enter  or 
leave  that  side  of  a box.  This  is  illustrated  in  Figure 
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control 

input 

(activity 
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output 
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mechanism 

Figure  43-  Structured  Analysis  Box  Labeling 


Each  of  the  four  types  of  interface  arrows  represents 
a particular  kind  of  interface.  For  an  activity  diagram, 
the  interfaces  between  activity  boxes  are  data  items,  since 
data  is  commonly  passed  back  and  forth  between  activities. 
The  interfaces  between  data  boxes  for  a data  diagram  are 
activities,  since  the  data  item  is  created  and  used  by  ac- 
tivities. The  ’'mechanism”  arrow  is  an  exception  to  these 
rules,  since  it  represents  the  mechanism  necessary  to  "rea- 
lize the  box".  The  mechanism  arrow  is  usually  not  shown 
on  the  diagram,  since  the  mechanism  is  usually  evident  from 
the  title  of  the  box.  * 

The  boxes  of  a diagram  (called  the  parent)  are  decom- 
posed into  smaller  boxes  in  another  diagram  (called  the 
child).  This  parent-child  relationship  is  represented  by 
the  node  number  assigned  to  a diagram.  For  example,  if 
diagram  "AO"  contains  three  boxes  numbered  from  one  to 
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three,  then  diagrams  "Al",  "A2"  and  "A3"  are  the  decomposi- 
tions (children)  of  the  respective  boxes  of  diagram  "AO". 

In  the  same  manner,  the  boxes  of  diagram  "Al"  (which  can 
nov;  be  considered  a parent)  can  be  decomposed  in  diagrams 
"All",  "A12",  etc.,  depending  on  the  number  of  boxes  con- 
tained in  diagram  "Al". 

Basic  Reading  Sequence 

The  following  reading  sequence  is  recommended,  taking 
the  diagrams  in  a top-down  order: 

1.  Scan  only  the  boxes  of  the  child  diagram  to  gain 
an  impression  of  the  module  decomposition. 

.Using  the  oarent  diagram,  rethink  the  message  of 
the  parent  module,  observing  the  arrows— feeding . t5  and 
from  the  parent  module. 

3.  Referring  back  to  the  child  module,  see  how  and 
where  each  arrow  from  the  parent  context  attaches  to  the 
factors  of  the  child  module. 

4.  Next  consider  the  internal  arrows  of  the  child 
modulo  to  see  the  details  of  how  it  works.  Consider  the 
boxes  from  top  to  bottom  and  from  left  to  right.  The  ar- 
rows should  be  examined  in  a clockwise  manner,  going  around 
each  box. 

5.  Finally,  read  the  text  for  the  child  diagram  to 
confirm  or  alter  the  interpretation  gained  from  considering 
the  diagrams  themselves. 
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